The present invention relates to equipment items installed on board vehicles and more particularly to a method for operating such an on-board equipment item, comprising an on-board micro software program that is executed to achieve at least one secure processing with the aid of sensitive security data.
The equipment items installed on board vehicles traditionally have a physical part, also known as “hardware” and a software part composed of programs, or “software”, executed by the hardware part. These different hardware and software components are identified by an identification number, or part number, especially in the aeronautics sector.
The hardware components may contain base software programs, such as BIOS, an operating system or a startup sequence (“boot” sequence according to English terminology).
These software programs generally have low application level and are integrated into a permanent memory. Any modification made to them is considered to be a “hardware” intervention on the affected component, necessitating a new certification cycle, because the new software code may modify the operation of the equipment item and in this regard must be verified and validated. This modification is known as a “hardware modification”.
Because a new hardware certification cycle is costly from the viewpoint of economics and time, such a hardware modification is considered to be a handicap in terms of operability and costs.
Thus it is commonly provided that only the executable software code, which is assumed will change not at all or only very little during the life of the vehicle, will be integrated into a hardware component. This software code integrated into the hardware component is also known as micro software or firmware according to a widely used Anglicism. The expressions “internal software”, “on-board software” or “operating software” are also used to designate this micro software.
Micro software is generally limited to the association of a startup program (“Boot software” according to English terminology) for starting up the equipment item and a resident program (“Resident software” according to English terminology) comprising some basic functions. These two elements of the micro software are executed successively during power-up of the equipment item in which they are integrated.
The interest of the invention lies in a micro software program capable of executing a secure processing operation by using sensitive security data.
By way of example in the aeronautics sector, a micro software program is reduced to the strict minimum and includes only communication and data-loading functions. These functions make it possible to load, from a data loader or a network loading server, operating data (software programs, applications and/or raw data) that impart to the on-board equipment item the functionalities to which it is dedicated.
These data are generally compiled and grouped in the form of files or blocks that can be downloaded to the aircraft in conformity with a standard provided for civil aviation. These files or blocks that the micro software loads can be referred to indiscriminately as “loads”.
To avoid compromising the operation of the aircraft, the files to be downloaded are secured by electronic (or digital) signatures, for example by means of a public key infrastructure (PKI), with which their authenticity can be verified.
The use of a PKI infrastructure and of corresponding asymmetric keys is made necessary for an aeronautical use, for example, by the fact of the plurality of entities involved in the operation of a type of aircraft: numerous file editors, numerous airline companies receiving these files, etc. Infrastructures having symmetric keys could not have been advisable, because these keys would have been shared by an excessive number of persons.
The files to be loaded, and especially their digital signatures, are then verified by the on-board equipment item before they are downloaded to the aircraft.
Patent Application FR 2912578 in particular describes digital signature mechanisms adapted to the aeronautics sector.
Nevertheless, to permit some flexibility in use of these signature mechanisms, such as an update, the tools necessary for these verifications (electronic keys, associated signature verification software programs) are integrated into one or more files to be downloaded, known as “configuration files”. This file constitutes or these files constitute the first data loaded into the on-board equipment item, since it is necessary for loading other files. This or these initial configuration file or files of the on-board equipment item is or are therefore designated as being the “first” file to be downloaded or “first configuration load”. For evident reasons of system security, this first file is also secured.
However, verification of this first “load” constitutes a difficulty, because the on-board equipment item is limited at that moment to the simple resident software as far as functionalities are concerned.
Referring to FIG. 1, there is illustrated the current process of loading files to be downloaded to aircraft in service.
On-board equipment item 10, which may be an avionic equipment item, for example, comprises among other features a set of hardware components provided with a micro software program 12, and software programs or data stored in a storage memory 14 while they are being downloaded, and a random-access memory 16, of SDRAM type, for example, for execution of software programs by executing means of on-board equipment item 10.
During startup of on-board equipment item 10, boot sequence 20 of micro software program 12 is loaded into random-access memory 16 then is executed to verify the state of the on-board equipment item.
If the first configuration data, or in other words the “first configuration load” 30 are not present in storage memory 14 of on-board equipment item 10, boot sequence 20 launches execution of resident software 22, which in turn is loaded into random-access memory 16.
In its binary code, resident software 22 comprises cryptological tools 24 of public key infrastructure type, especially to verify the signature of first “configuration load” 30, which contains the sensitive data (PKI parameters) for verifying the other files 34 to be downloaded. These tools are in particular a root certificate, a hash algorithm, a signature algorithm and a binary software code for electronic signature verification. Resident software 22 also comprises tools for communication with a centralized data loader (not illustrated), for example via a communication network, from which equipment item 10 is able to recover the files to be downloaded.
In this way, first “configuration load” 30 signed in conformity with a public key infrastructure PKI is verified by resident software 24 according to traditional PKI signature verification mechanisms. This first configuration file is loaded into storage memory 14 only after positive verification, or in other words when the origin and integrity of the file are correct.
Once first “configuration load” 30 and therefore tools 32 for verification of the signature of the other files 34 to be downloaded, especially PKI parameters (certificates, algorithms) and corresponding software programs are available to it, on-board equipment item 10 proceeds to verification of the subsequent files 34 and to loading them in memory 14 from the data loader, when the verification of first “load” 30 by means of the PKI parameters is positive.
These other downloaded files 34 comprise diverse applications or operating data for equipment item 10.
In this configuration, the sensitive data, here the PKI parameters for secure processing of verification of the first configuration file to be downloaded, are contained in the binary code of resident software 22.
During subsequent startups of the on-board equipment item, the latter launches boot sequence 20 and verifies the presence of first configuration file 30 in permanent memory 14. Since the first configuration file of equipment item 10 is present (loaded during the first startup of equipment item 10), resident software 22 is ignored.
The PKI parameters and software tools 32 necessary for verification of the electronic signature of the subsequent files 34 are loaded into SDRAM memory 16 from the data of first configuration file 30 stored in permanent memory 14. Downloading of subsequent files 34 from the data loader is identical to the process described hereinabove.
However, the PKI parameters necessary for verification of the files may evolve in time, for example for the following reasons:                a root certificate has a limited life, often of 20 years, which is clearly shorter than the useful life of an aircraft on which equipment item 10 is installed;        the algorithms are subjected to mathematical attacks that may be employed by virtue of increasing computing power. Thus these algorithms are modified as a function of advances in cryptoanalysis.        
In this way the electronic signature solution for the operating files will go through several successive versions: N, N+1, etc.
To facilitate migrations from one version to another, a transition period is decided for a duration of some months or years whenever possible. During this period, the signature versions N and N+1 coexist. At the end of this period, the use of version N is prohibited, since it is considered to be unsafe:                the initial files signed N must no longer be used, because of the loss of total confidence in signatures in the previous version,        only new files signed N+1 may be generated, and must be used.        
When this evolution affects signature verification tools 32 used for loading subsequent files 34, an update of first configuration file 30 in on-board equipment item 10 is conducted by downloading a new corrective file signed N (also known as “patch”) and containing the new PKI parameters.
By virtue of the new PKI parameters of configuration file, updated by patch, subsequent files 34, signed with the new signature version N+1, can be verified before being installed in on-board equipment item 10.
In the case that on-board equipment item 10 is reset to zero, entailing erasure of first configuration file 30 from memory 14, a new first configuration file 30 comprising verification tools 32 in version N+1 must be available from the data loader.
When the evolution of electronic signature mechanisms affects signature verification tools 24 used for loading first configuration file 30, the new first configuration file 30 to be loaded and intended for on-board equipment item 10 is signed from then on in version N+1.
In its binary code, however, resident software 22 comprises only the PKI parameters for verifying a signature of configuration file 30 in version N.
In this configuration, when on-board equipment item 10 is reset to zero and first configuration file 30 must be reloaded, verification of this first file cannot be achieved because of incompatibility of the signature versions. Consequently, downloading of this file 30 and of subsequent files 34 is blocked.
The hardware configuration of equipment item 10 must therefore be modified to integrate the PKI parameters in version N+1 into resident software 22. As mentioned hereinabove, this evolution or update of PKI parameters 24 modifies the on-board software code and necessitates a new cycle of certification of equipment item 10, with the consequence in general that it must be removed and returned to the supplier of equipment item 10.
In general, when an on-board equipment item comprises micro software capable of executing a secure processing, and this micro software integrates the sensitive security data used by this processing, it is necessary to undertake a new certification of the equipment item when it is desired to modify these sensitive data.